Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]` #142681

1c3t3a · 2025-06-18T15:15:04Z

This came up during the sanitizer stabilization (#123617). Instead of a #[no_sanitize(xyz)] attribute, we would like to have a #[sanitize(xyz = "on|off")] attribute, which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off). The implementation is done according to what was discussed on Zulip).

The new attribute also works on modules, traits and impl items and thus enables usage as the following:

#[sanitize(address = "off")]
mod foo {
    fn unsanitized(..) {}

    #[sanitize(address = "on")]
    fn sanitized(..) {}
}

trait MyTrait {
  #[sanitize(address = "off")]
  fn unsanitized_default(..) {}
}

#[sanitize(thread = "off")]
impl MyTrait for () {
    ...
}

r? @rcvalle

rustbot · 2025-06-18T15:15:13Z

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes.

cc @BoxyUwU, @jieyouxu, @Kobzol

triagebot.toml has been modified, there may have been changes to the review queue.

cc @davidtwco, @wesleywiser

Some changes occurred in src/doc/unstable-book/src/language-features/no-sanitize.md

cc @rust-lang/project-exploit-mitigations, @rcvalle

Some changes occurred in tests/codegen/sanitizer

cc @rcvalle

Some changes occurred in tests/ui/sanitizer

cc @rcvalle

Some changes occurred in compiler/rustc_codegen_ssa/src/codegen_attrs.rs

cc @jdonszelmann

rcvalle · 2025-06-18T15:18:12Z

Thank you very much for your time and work on this, @1c3t3a! Much appreciated.

rcvalle · 2025-06-18T15:18:41Z

cc @Darksonn @wesleywiser @traviscross

Darksonn · 2025-06-18T18:22:06Z

It doesn't matter for me, but should we make this change gradually by supporting both for some time?

1c3t3a · 2025-06-18T21:32:33Z

It doesn't matter for me, but should we make this change gradually by supporting both for some time?

That's possible for sure, I put stuff into different commits for that reason and I can just drop the middle commit to have both exist in parallel.

What's the reason for having both at the same time? An easier migration period?

traviscross · 2025-06-19T02:53:55Z

We generally do not make such efforts to migrate usage of nightly features without a specific known good reason to do so. (Let us know of course if there is one, e.g. if this affects RfL in some way.)

bors · 2025-06-20T13:59:53Z

☔ The latest upstream changes (presumably #142770) made this pull request unmergeable. Please resolve the merge conflicts.

ojeda · 2025-07-01T17:23:20Z

e.g. if this affects RfL in some way.

We don't use #[no_sanitize] in mainline (nor in -next) at the moment.

1c3t3a · 2025-07-14T14:25:46Z

I rebased the change to make review easier.

jieyouxu

Note that if this is a built-in attribute, then IIUC #[sanitize] (even if unstably gated) could introduce new name resolution ambiguities with user macros or derive macro attributes and thus technically break existing user code. See for instance #143834. cf. #134963.

// tests/ui/whatever_subdir/test.rs

//@ proc-macro: my_derive.rs
//@ edition: 2024

use my_derive::MyDerive;

#[derive(MyDerive)]
#[sanitize]
//~^ ERROR `sanitize` is ambiguous
pub struct Foo;

fn main() {}

// tests/ui/whatever_subdir/auxiliary/my_derive.rs

//@ edition: 2024

extern crate proc_macro;
use proc_macro::{Span, TokenStream};

#[proc_macro_derive(
    MyDerive,
    attributes(
        sanitize
    )
)]
pub fn derive_custom(_item: TokenStream) -> TokenStream {
    TokenStream::new()
}

You can still observe this for #[no_sanitize] too, if you switch sanitize for no_sanitize in the above test case.

error: malformed `no_sanitize` attribute input
  --> /home/joe/repos/rust/tests/ui/bitbuffer_derive/test.rs:7:1
   |
LL | #[no_sanitize]
   | ^^^^^^^^^^^^^^ help: must be of the form: `#[no_sanitize(address, kcfi, memory, thread)]`

error[E0659]: `no_sanitize` is ambiguous
  --> /home/joe/repos/rust/tests/ui/bitbuffer_derive/test.rs:7:3
   |
LL | #[no_sanitize]
   |   ^^^^^^^^^^^ ambiguous name
   |
   = note: ambiguous because of a name conflict with a builtin attribute
   = note: `no_sanitize` could refer to a built-in attribute

error[E0658]: the `#[no_sanitize]` attribute is an experimental feature
  --> /home/joe/repos/rust/tests/ui/bitbuffer_derive/test.rs:7:1
   |
LL | #[no_sanitize]
   | ^^^^^^^^^^^^^^
   |
   = note: see issue #39699 <https://github.com/rust-lang/rust/issues/39699> for more information
   = help: add `#![feature(no_sanitize)]` to the crate attributes to enable
   = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date

error: aborting due to 3 previous errors

Some errors have detailed explanations: E0658, E0659.
For more information about an error, try `rustc --explain E0658`.

Or just

macro_rules! sanitize {
    () => {
        /* .. */
    };
}

pub(crate) use sanitize; // `use` here becomes ambiguous

fn main() {}

I imagine no_sanitize is much less likely to collide with something a user would write (not an argument against this change, just an observation re. technically a breaking change).

I don't know how much of a concern for breakage this is in practice, a crater run may or may not be a good idea. If the breakage is deemed acceptable, then this should get relnotes.

bors · 2025-07-14T16:26:31Z

☔ The latest upstream changes (presumably #143919) made this pull request unmergeable. Please resolve the merge conflicts.

traviscross · 2025-07-14T19:22:59Z

@rustbot labels +T-lang +needs-fcp
cc @rust-lang/lang

Given that this is breaking, we should review and FCP. Let's do that crater run, since we'll need it for our review.

@bors2 try

traviscross · 2025-07-20T11:40:24Z

The regressions all look spurious to me.

1c3t3a · 2025-07-22T17:44:16Z

I agree, also running rg -U --multiline-dotall -e 'no_sanitize is ambiguous' --files-with-matches | cut -d/ -f1 | counts doesn't return any results, so it seems like nobody redefined this attribute so far.

This change implements the #[sanitize(..)] attribute, which opts to replace the currently unstable #[no_sanitize]. Essentially the new attribute works similar as #[no_sanitize], just with more flexible options regarding where it is applied. E.g. it is possible to turn a certain sanitizer either on or off: `#[sanitize(address = "on|off")]` This attribute now also applies to more places, e.g. it is possible to turn off a sanitizer for an entire module or impl block: ```rust \#[sanitize(address = "off")] mod foo { fn unsanitized(..) {} #[sanitize(address = "on")] fn sanitized(..) {} } \#[sanitize(thread = "off")] impl MyTrait for () { ... } ``` This attribute is enabled behind the unstable `sanitize` feature.

This removes the #[no_sanitize] attribute, which was behind an unstable feature named no_sanitize. Instead, we introduce the sanitize attribute which is more powerful and allows to be extended in the future (instead of just focusing on turning sanitizers off).

rustbot · 2025-07-23T14:49:17Z

Some changes occurred in tests/codegen-llvm/sanitizer

cc @rcvalle

…ress To do it the same as how clang disables address sanitizer, we now disable ASAN on sanitize(kernel_address = "off") and KASAN on sanitize(address = "off"). The same was added to clang in https://reviews.llvm.org/D44981.

1c3t3a · 2025-07-24T13:26:41Z

Is there anything else needed for this change before landing? To summarize:

This switches directly from no_sanitize to sanitize. Rust for Linux is currently not using the attribute and the crater run revealed two users that depend on it: https://github.com/keepitupkitty/ouma and https://github.com/lz520520/rust-1.75-ollvm, both of which seem unmaintained.
There is also no collision between the new sanitize attribute and other, custom macro implementations, according to the data from the crater run.

traviscross · 2025-07-24T22:45:38Z

Given the clean crater run and the likelihood that we will want to use this attribute for this purpose, I propose that we accept this breakage and the use of this attribute for this experimental work.

@rfcbot fcp merge

rfcbot · 2025-07-24T22:45:40Z

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

RalfJung · 2025-07-25T06:40:16Z

FWIW, #[sanitize(address = "off")] seems a bit inconsistent with #[target_feature(enable = "avx")], in terms of how we represent "turn this thing on/off". But I am not sure if it's worth trying to be consistent here -- having an ad-hoc list in the string value of an attribute key (i.e., what target_feature does) seems worse than using the fact that attributes already support lists of key-value pairs (i.e., what sanitize does).

I assume the syntax to disable multiple sanitizers is #[sanitize(address = "off", thread = "off")]?

1c3t3a · 2025-07-25T08:14:43Z

This attribute is more akin to the coverage attribute #[coverage(off)]. If we were to go with the same approach as target_feature we'd have something like the following syntax to disable multiple sanitizers #[sanitize(off = "address,thread", on = "cfi,memory")] or #[sanitize(off = "address", off = "thread", on = "cfi", on = "memory")].

I assume the syntax to disable multiple sanitizers is #[sanitize(address = "off", thread = "off")]?

Yes indeed!

RalfJung · 2025-07-25T10:03:57Z

If we were to go with the same approach as target_feature we'd have something like the following syntax to disable multiple sanitizers #[sanitize(off = "address,thread", on = "cfi,memory")] or #[sanitize(off = "address", off = "thread", on = "cfi", on = "memory")].

Yeah... that looks terrible.^^ But it seemed worth mentioning in terms of evaluating consistency across the language.

tmandry · 2025-07-26T00:09:00Z

I wish we had some philosophy for how to spell these attributes. Why should it be #[sanitize(address = "off")] and not #[sanitize(address(off))] or #[sanitize(address = off)]?

Since the lang team hasn't developed our own answers to these questions though, I'm inclined not to block. There's not a practical reason to spell it one way or the other, and we can make these things more consistent in a future edition.

@rfcbot reviewed

traviscross · 2025-07-26T03:32:01Z

Since the lang team hasn't developed our own answers to these questions though, I'm inclined not to block. There's not a practical reason to spell it one way or the other, and we can make these things more consistent in a future edition.

Note in particular that we're not stabilizing this or even agreeing necessarily to the details of the syntax. We're just accepting the breaking change required to use the sanitize attribute for this experimental work in nightly (on the presumption that we are likely to use this attribute when later stabilizing).

rfcbot · 2025-07-26T04:08:44Z

🔔 This is now entering its final comment period, as per the review above. 🔔

luca3s · 2025-07-26T11:52:23Z

src/doc/unstable-book/src/language-features/sanitize.md

+atomic operations to avoid reporting false positives and provide meaning full
+stack traces.
+
+This attribute was previously named `no_sanitized`.


Suggested change

This attribute was previously named `no_sanitized`.

This attribute was previously named `no_sanitize`.

rustbot assigned rcvalle Jun 18, 2025

rcvalle mentioned this pull request Jun 18, 2025

sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets #123617

Open